Modern electronic design is typically performed with computer aided design (CAD) tools or electronic design automation (EDA) systems. To design an integrated circuit, a designer first creates high level behavior descriptions of the IC device using a high-level hardware design language (HDL). Common examples of HDLs include Verilog and VHDL. An EDA system typically receives the high level behavioral descriptions of the IC device and translates this high-level design language into netlists of various levels of abstraction. Essentially, the process to implement an electronic device begins with functional design and verification (e.g., using RTL), and then proceeds to physical design of a layout and verification.
Circuit designers and verification engineers use different methods to verify circuit designs. One common method of verification is through simulation of the circuit design of interest. Simulation dynamically verifies a design by monitoring behaviors of the design with respect to test stimuli. For many types of designs, simulation can and should be performed during the design process to ensure that the ultimate goals are achievable and will be realized by the finished product.
SPICE (Simulation Program with Integrated Circuit Emphasis) is a common type of simulator that is used to simulate and verify the operation of an electronic design. With SPICE, the electronic design is converted into a system of equation(s), which is then solved for a given set of inputs to check the state of specific portions of the circuit at given points in time. Furthermore, capturing the electrical behaviors of a circuit design requires correctly modeling various components of a circuit design to include, for example, geometric information, parasitic information, etc. Although many vendors provide, for example, SPICE models, s-parameter models, etc. for their devices, an IC design or a system design may involve much more than merely these device models for simulation. For example, the packaging may need to be properly accommodated in such models, the traces or interconnects may need to be modeled to reflect more realistic voltage drops, etc. For many circuit designs, this process can be a very computationally expensive and time-consuming effort, especially given the size and complexity of modern circuit designs.
Conventional approaches for simulations, especially for board or system level simulations (e.g., simulations performed on an electronic system including the printed circuit board or PCB, one or more integrated circuit (IC) chips, and IC packaging thereof) often extract a static simulation view from layouts (e.g., IC layout, package layout, board layout, etc.) by identifying a corresponding schematic symbol from the schematic symbol library for each of a plurality of layout circuit devices, invoking the corresponding layout editor, and performing the extraction therein. The extraction results are then saved as some textual form (e.g., an ASCII file for a SPICE netlist). As a result, these simulation views are often termed layout extracted views or simply extracted views; and they are understandable by the simulators but not much more beyond that. That is, the graphical representations or a simplified version thereof representing how circuit components are connected may be lost in the generation of these conventional extracted views. The electronic design may then undergo multiple rounds of changes to the schematic, the layout, or both the schematic and the layout after the initial simulation has been performed with a simulation view extracted from the initial layout.
When these changes occur at the schematic level, these conventional approaches require a designer to implement the changes in the schematic of the electronic design, push these schematic changes to create an updated layout with a layout editor, and then extract an updated simulation view with the updated layout. The simulator may then perform another round of simulation with the updated simulation view. This loop not only requires much more time and computational resources but also presents multiple other problems.
For example, modern electronic design may include devices having distributed pins, vector pins, etc. that may be represented as an input pin in the schematic symbol. During a simulation of, for example, an electronic design with a distributed Vcc having multiple Vcc pins for a distributed power network, this distributed Vcc may be schematically represented as a single Vcc pin in the corresponding schematic symbol. In this example, if the simulation result for the Vcc shows abnormal behavior the designer will need to guess which Vcc pin or Vcc pins are causing the abnormal behavior or perform some trial-and-error changes to identify the true cause of the abnormal behavior. Similar problems and hence challenges also arise for vector pins which may be even more difficult to troubleshoot and identify the root source of any abnormal behavior simulation result due to the multiplicity of the pins.
Another problems with these conventional approaches is that the extracted view from a layout is a static view. These simulation views are generated by traversing a layout to identify layout component designs and devices, identify a corresponding schematic symbol for each of the layout component designs, place the schematic symbol in the simulation view, and interconnect the schematic symbols by referencing the layout connectivity. Although these simulation views may in some cases appear to be identical or substantially similar to the original schematic from which the layout is generated, these simulation views or extracted views are not editable as the original schematic. As a result, any changes at the schematic level must go through the aforementioned schematic edit, layout edit, and re-extraction.
Moreover, these simulation views are often generated for the simulation engines and thus do not appear as readable or understandable by designers. More importantly, these extracted views are generated as a flat view having a single hierarchy that includes all the schematic symbols or models understood by the simulation engine. As a result, an extracted view loses the hierarchical structures of the electronic designs; and the loss of the hierarchical structure further exacerbates the difficulties in understanding or manipulating such an extracted view, even if the extracted view were to be editable.
Another problem with conventional approaches is that the same schematic symbol may correspond to multiple schematic instances in the schematic design and hence multiple layout instances in the layout. During the generation of an extracted view from the layout in conventional approaches, these multiple layout instances may be extracted and represented as the same schematic symbol whereas these multiple layout instances may not necessarily be identically implemented in the layout. For example, two or more of these multiple layout instances may be routed differently although then all correspond to the same schematic symbol. As a result, conventional simulation views cannot correct capture the differences in, for example, parasitics and/or electrical characteristics between these layout instances.
In addition to the aforementioned problems, what actually predicts the predicted behaviors is the extracted views because these extracted views model at least the components that may affect the electrical behaviors of the underlying circuit. Nonetheless, designers and users of various electronic design tools are more used to view and interact with schematic designs because a schematic design delineates how circuit components are interconnected with each other although the schematic design may not indicate or even imply the scales or sizes of these circuit component designs. As described above, conventional extracted views are obtained from various layouts and are created in a form (e.g., ASCII file) that is understood by the simulators (e.g., SPICE simulators) but not the users, at least not in a graphical way that resembles how circuit component designs are interconnected. Although these extracted views may be back annotated or associated with the underlying schematic, these extracted views are not intuitive and not understandable unless the users parse through the textual description therein. Moreover, even if users can parse through these extracted views and understand their contents, these conventional extracted views often cluttered the design space and thus provide not much value, if any at all, for users to perform their intended tasks.
At Giga-hertz (GHz) frequencies, long interconnect leads may exhibit transmission line behavior because of the fast rise/fall times of signals. Moreover, with the use of wider wires, inductive impedance (jωL) at high frequencies (e.g., microwave, RF or radio frequency, etc.) becomes comparable to the resistive component (R) of the major signal wires and power/ground nets. For copper wires, this phenomenon becomes even more prominent. Such parasitic inductance may cause additional signal delays, over-shoot waveforms, increased ground bounce, and inductive crosstalk so clock trees and the power/ground grids need to be designed more carefully to avoid large clock skew, signal inductive coupling, ground bounce, etc.
Conventional approaches merely consider the inductive effects of interconnect leads only for a few global clock wires and major signal buses. This has been proved to be insufficient because of higher clock frequencies and faster signal rise/fall times. Three-dimensional (3D) or two-and-a-half (2.5D) electromagnetic (EM) full wave field solvers are available but do not have the capacity to manage modern ICs and often become prohibitively expensive, especially those having large, complex circuits. These problems and challenges are in addition to those pertaining to conventional, layout-driven extracted views.
Thus, what are needed are methods, systems, and computer program products for implementing a net as a transmission line model in a schematic driven extracted view for an electronic design to address at least the aforementioned issues and shortcomings.